Interview Playbook [DS/A]

1
Clarify the inputs
"Before I start, can I ask a few questions about the input?"
  • Type & shape: array, string, tree, graph? Nested? Sorted?
  • Size / range: how big is n? Hints at target complexity.
  • Value bounds: negatives, zero, duplicates, empty, null?
  • Characters/encoding: ASCII vs unicode, case sensitivity, whitespace.
  • Output: return value vs mutate in place? Any specific format?
  • Guarantees: is a solution always valid? Ties broken how?
2
Restate + walk an example
"So given X, I should return Y — is that right?"
  • Repeat the problem in your own words to confirm understanding.
  • Trace one normal example by hand to lock in the mapping.
  • List edge cases now (empty, single element, all same, huge).
  • Write them as pending test cases so you don't forget to check them.
3
Outline the solution
"Here's my plan — let me know if you see an issue before I code."
  • State the approach in plain English before any syntax.
  • Name the data structure & why (hash map for O(1) lookup, etc.).
  • Mention the brute force, then the optimization you'll actually write.
  • Get a nod from the interviewer — course-correct cheaply here, not after 30 lines.
4
State time & space
"This is O(n) time, O(n) space — the map dominates."
  • Give Big-O for time and space before coding, then reconfirm after.
  • Tie it to n: does it match the input size they hinted at?
  • Call out the trade-off you chose (speed vs memory vs simplicity).
  • If it's not optimal, say so and note what a better bound would take.
5
Code — clean & out loud
"I'll pull the dedupe into a helper so it's easy to test."
  • Narrate as you type — never go silent for minutes.
  • Meaningful names, small helper functions, testable units.
  • Handle the guard clauses (empty/null) first, then the core.
  • Simplest structure that works — a list beats a map if a list does the job.
  • Don't stall on syntax; you picked the language, know the basics.
6
Test it yourself
"Let me run through my edge cases before I call it done."
  • Run your edge cases from step 2: empty, size 1, size 2, negatives, dupes.
  • Then a normal case to prove it works beyond the corners.
  • Trace line-by-line or actually run it — don't assume it's correct.
  • Find your own bug before the interviewer does; fix and re-run.

Clarifying questions to keep in your pocket

How large can n get?
Can the input be empty or null?
Are there duplicates?
Is it sorted?
Negative numbers / zero?
Is there always a valid answer?
Return or mutate in place?
How are ties broken?
Case-sensitive?
Optimize for time or space?
Can I use built-in libraries?
Multiple valid outputs OK?

If you get stuck or run low on time

  • Stuck: think out loud, shrink the problem, or solve brute force first — a working slow answer beats a broken fast one.
  • Hint offered: engage with it. You needn't accept, but give a clear reason if you don't.
  • Out of time: say what you'd refactor and what edge cases you'd still test before it's "production ready."

What they're actually scoring

  • Communication: reasoning shared, not stuck in your head.
  • Correctness: it runs and handles edge cases.
  • Simplicity: right data structure, no over-engineering.
  • Maintainability: good names, helpers, light comments.
  • Complexity awareness: you know your Big-O and trade-offs.
Clarify → Example → Outline → Complexity → Code → Test. Keyboard comes after step 4.